マルチアカウント環境をらくらく統制！AWS Control Towerの一般提供が開始されました！

#AWS Control Tower

#AWS

中山順博

2019.06.25

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

中山です

昨年のre:Invent 2018でLimited Previewが開始されたAWS Control Towerですが、本日一般提供が開始されました！

AWS Control Tower is now generally available

Control Towerが提供される背景

複数のAWSアカウントを管理する際、どのように統制するかは大きな課題です。権限を絞りすぎると開発や運用の効率は悪くなりますし、自由にさせすぎるとリスクが増大します。

権限は大きめに与えつつも監査可能性を担保したりリスクが大きくなる部分は自動で問題を是正するようにするなどの対策が考えられますが、「具体的にどうするの？」と言われると即答できる組織／人は少ないんじゃないかと思います。

そこで登場したのがLanding Zoneです。

Landing Zoneは、組織で複数のAWSアカウントを管理する際のベストプラクティスです。具体的には、ログの集約やセキュリティの管理などを担う共用のアカウントとサービスを提供するための個別アカウントに分けて管理することや個別アカウントに設定しておくべきことなどが定義されています。詳細は以下のサイトでご確認ください。

AWS Landing Zone

しかし、あるべき状態を定義できたとしても、そのための土台を実装したり複数のAWSアカウントに展開／維持するのは大変です。

AWS Control Towerはマルチアカウント管理におけるベストプラクティスとそれを展開するマネージドサービスです。

What Is AWS Control Tower?

やってみた

実際に利用してみるのが手っ取り早いので、早速やってみました。

前提

検証にあたり、Organizationsを有効化していない、できたてほやほやのAWSアカウントを利用しました。

また、現在は北米の4リージョンのみで提供されていますが、今回はオレゴンリージョンで試してみました。

Landing Zoneの作成

まずは、起点となる "Landing Zone" を作成します。

Landing Zoneを作成することで、ログの集約とアカウントの監査のための共用アカウントが作成されます。そのAWSアカウントために、メールアドレスを指定します。

Landing Zoneを作成するにあたり用意したAWSアカウントに3つのIAM Roleが作成されますが、そのポリシーをここで確認可能です。

Landing Zoneの作成を開始します。処理の完了にはおおよそ1時間かかるようです。

すると、何種類かのメールが送られてきました。

まずは、用意したAWSアカウントをOrganizationsの管理下とすることを確認するメールが送られてきました。

クリックすると、Organizationsが有効化されてることを確認できます。また、共用のアカウントがすでに作成できていることも確認できます。

また、各AWSアカウントが所定のOUに配置されていることも確認できました。

最初に用意したAWSアカウント（以降、Masterアカウント）はRootに配置されています。

Coreには共用の2アカウントが作成されています。

CustomにはLanding Zoneを作成した時点ではAWSアカウントは配置されていません。

次に、AWS SSOの招待メールを受信しました。

Masterアカウントのメールアドレスでユーザーが作成されます。

SSOユーザーのためのパスワードを登録します。

ログインすると、すでに各アカウントがAWS SSOに登録済みとなっていました。また、作成したユーザーではいくつかのアクセス権限セットを利用してマネージメントコンソールにアクセスできるようになっています。

次に、Consolidated Billingの処理が完了したメールを受信しました。特に追加のアクションは不要です。

最後に、監査用の共用アカウントでSNS TopicおよびSubscriptionが作成されるため、Subscriptionを承認します。 SNS TopicはControl Towerをサポートする4リージョンで作成されるようです。用途はよくわからなかったので、後日調べてみようと思います。

これでLanding Zoneの作成が完了です。

Account Factoryでアカウントの作成

次に、AWSアカウントの新規作成を行ってみます。

ちなみに、AWSアカウントを作成するにあたり、作成するVPCの属性をある程度指定できるようです。

「新しいアカウントのプロビジョニング」をクリックすると、Service Catalogのコンソールに遷移します。

"AWS Control Tower Account Factory" を選択します。

「製品の起動」をクリックします。

Service Catalog上での識別子となる名前を設定し、次に進みます。

各種パラメーターを入力します。

ここでは、AWSアカウントに使用するメールアドレスやAWSアカウントを配置するOU、AWS SSO用のユーザー名（メールアドレス）などを指定します。

ここで指定するAWS SSO用のユーザーには作成されるAWSアカウントの管理権限が付与されます。

必要に応じてタグや通知設定を行います。

最後にパラメーターを確認し、「起動」をクリックします。

しばらくすると、Organizations上でもAWSアカウントが作成されたことが確認できました。

指定したOUにも配置されています。

また、AWS SSOのユーザー招待メールも受信していました。

AWS SSO上でも作成したAWSアカウントが登録されていることを確認できます。以下の画面は新たに作成されたSSOユーザでログインしたときの画面です。管理者用のアクセス権限セットが割り当てられています。

Guardrailsでリスクの発生を予防／検出

次にGuardrailsの設定を見ていきましょう。

Control TowerのGuardrailsでは「予防」と「検出」の2種類のGuardrailsを提供しています。

予防はOrganizationのSCP(Service Control Policy)を利用して基準から外れるようなアクションを制限します。検出はConfig Rulesを利用して基準から外れているリソースを検出します。そのための設定をControl Towerが自動で実施してくれます。

Control TowerのコンソールでGuardrailsの一覧を確認できます。

予防のGuardrailsの実体がSCPであることも確認できます。以下のポリシーは、「ログアーカイブへのポリシーの変更を不許可にする」の実体となるポリシーです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GRAUDITBUCKETPOLICYCHANGESPROHIBITED",
            "Effect": "Deny",
            "Action": [
                "s3:PutBucketPolicy"
            ],
            "Resource": ["*"],
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN":"arn:aws:iam::*:role/AWSControlTowerExecution"
                }
            }
        }
    ]
}

検出のGuardrailsの実体がConfig Rules（を作成するCloudFormation Template）であることも確認できます。以下のテンプレートは、「ログアーカイブへのパブリック読み取りアクセスを不許可にする」の実体となるConfig Ruleを作成するCFnテンプレートです。

AWSTemplateFormatVersion: 2010-09-09
Description: Configure AWS Config rules to check that your S3 buckets do not allow public access
Parameters:
  ConfigRuleName:
    Type: 'String'
    Description: 'Name for the Config rule'
Resources:
  CheckForS3PublicRead:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: !Sub ${ConfigRuleName}
      Description: Checks that your S3 buckets do not allow public read access. If an S3 bucket policy or bucket ACL allows public read access, the bucket is noncompliant.
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket